38.5 KB · ⇊ 11 parts · ⤓ Micron 38.5 KB · ⤓ HTML 73.3 KB

layout: Wide · Narrow · Centered

top

The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Before its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfillment system.cite-ref-0-1-0[1]

EPP is based on XML - a structured, text-based format. The underlying network transport is not fixed, although the only currently specified method is over TCP. The protocol has been designed with the flexibility to allow it to use other transports such as BEEP, SMTP, SOAP or HTTPS.cite-ref-0-1-1[1] However only HTTPS has seen some usage while the vast majority uses TCP.

• History

• Adoption

• Protocol commands

• Example

• Extensions

• Result codes

• EPP object status codes

• Security considerations

• Related RFCs

• EPP Objects RFCs

• EPP Extension RFCs

• See also

• References

The first protocol drafts were published as IETF individual submission Internet Draft documents by Scott Hollenbeck of Verisign in November 2000.cite-ref-2[2] The individual submission documents were adopted by the IETF Provisioning Registry (provreg) working group, which was created after a BoF session was held at IETF-49 in December 2000.cite-ref-3[3] Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004.cite-ref-4[4] Draft Standard documents (RFCs 4930 - 4934) were published in May 2007.cite-ref-5[5]

In August 2009, IETF granted EPP the status of full standard as STD 69.cite-ref-11-6-0[6]

The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004.cite-ref-1-7-0[7] Since then, several different proposed standard extensions followed.cite-ref-2-8-0[8]

The protocol has been adopted by a number of ccTLD domain name registries, such as: .ac, .ag, .ai, .as, .ar, .at, .au, .be, .br, .bz, .ca, .cat, .cc, .ch, .cl, .cn, .co, .cr, .cx, .cz, .dk, .dm, .ee, .es (over HTTPS), .eu, .fi, .fm, .fr, .gg, .gr (over HTTPS), .gs, .hn, .ht, .il, .im, .in, .io, .it (over HTTPS), .je, .ke, .ki, .ky, .kz, .la, .lc, .li, .lt, .lu, .lv, .md, .me, .mk, .mn, .ms, .mu, .mx, .na, .nf, .ng, .nl, .no, .nu, .nz, .pe, .pk, .pl (over HTTPS), .ps, .pt, .ru, .ro, .sc, .se, .sh, .si, .su, .tl, .tm .tv, .tw, .ua, .uk, .us, .vc, .ve and .za as well as ENUM registries such as those operating the +31, +41, +43, +44 and +48 country codes.cite-ref-9[9]

ICANN has made it a condition in their base registry contract to offer an EPP service. Therefore, every gTLD has adopted the protocol.cite-ref-10[10]

There are multiple open source implementations of EPP server software. The Council of Country Code Administrators (CoCCA) maintains an EPP server software used by around 59 ccTLDs and six gTLDs.cite-ref-11[11] Another open source software is FRED (maintained by CZ.NIC) which counts 11 ccTLDs as its users.cite-ref-12[12]

There are three classes of commands: Session management, query, and object transform. These commands can then be mapped onto objects, which specifies their exact functionality.cite-ref-0-1-2[1] The most common standardized objects are hosts,cite-ref-13[13] contactscite-ref-14[14] and domains.cite-ref-3-15-0[15] There are also other standardized objects like organizations,cite-ref-16[16] however they are rarely used.

When the client connects to a server, the server immediately sends a "greeting" message to the client. This message contains information about the server that the client needs to connect to. This contains the name of the server, the server's current date and time in UTC, the supported features, and a privacy policy. The supported features include EPP versions, languages, objects, and extensions.cite-ref-0-1-3[1]

The session management commands are:cite-ref-0-1-4[1]

| Command | Usage |

|---|---|

| hello | Request another "greeting" response fro… |

| login | Start a new session that will be kept o… |

| logout | End the current session. |

The query commands are:cite-ref-0-1-5[1]

| Command | Usage |

|---|---|

| check | Check whether an object is still availa… |

| info | Get all the current information about a… |

| poll | Read a message from the server for the… |

| transfer | Get the current status of a started obj… |

The object transform commands are:cite-ref-0-1-6[1]

| Command | Usage |

|---|---|

| create | Create a new object. |

| delete | Delete the object. Hosts and Contacts a… |

| renew | Increase the amount of time the domain… |

| transfer | Change the registrar/owner of the objec… |

| update | Update the object. This generally inclu… |

An example command to create a domain could look like this:

Note that the two host objects and three different contact objects had to be created beforehand to use them and the client had to be logged in already. The authInfo pw is a secret required in the transfer between registrars. The clTRID is a unique transaction ID for each command the client generates. A server response to the command above could look like this:

The clTRID is the same as the client sent, while the svTRID is a unique transaction ID the server generates. The server returns a result code, message, and additional result data, such as the expiration date of the newly created domain.

The protocol offers the ability to send an extension object on almost every possible command to enable registries to add new functionality without changing the base commands.cite-ref-0-1-7[1]

There are a few standardized extensions that are used by a lot of registries. These include extensions for DNSSEC,cite-ref-17[17] IDN,cite-ref-18[18] premium domain names,cite-ref-19[19] domain restoration (RGP)cite-ref-1-7-1[7] and extensions to handle the launch of new TLDscite-ref-20[20] and Registry Maintenancescite-ref-21[21] among other things.cite-ref-2-8-1[8]

Some registries also developed extensions that are specific to their TLDs. A common use case for non-standardized extensions is collecting extra data needed to create a domain, for example, a VAT identification number.cite-ref-2-8-2[8]

All responses from the server have to follow a specified format. Each response code corresponds to a human-readable message. Codes in the format 1xxx are successful operations, while codes in the format 2xxx are errors. The errors are again divided into protocol syntax errors in the format 20xx, implementation-specific rules as 21xx, security as 22xx, data management as 23xx, server system as 24xx, and connection management as 25xx. Most results can include additional data in the resData object, for example, which required parameter is missing.cite-ref-0-1-8[1]

The response code 1001 enables offline processing, an example for this can be that a domain name registry wants to validate a registrant before the domain is registered. In this case, the domain is blocked for other clients until the process is complete, and the client will be notified via a poll message that the client can fetch via the poll command. The codes 1300 and 1301 are specifically for the poll command and signal whether there is a message.cite-ref-0-1-9[1]

The complete list of standardized result codes and result messages is:cite-ref-0-1-10[1]

| Code | Message |

|---|---|

| 1000 | Command completed successfully |

| 1001 | Command completed successfully; action… |

| 1300 | Command completed successfully; no mess… |

| 1301 | Command completed successfully; ack to… |

| 1500 | Command completed successfully; ending… |

| 2000 | Unknown command |

| 2001 | Command syntax error |

| 2002 | Command use error |

| 2003 | Required parameter missing |

| 2004 | Parameter value range error |

| 2005 | Parameter value syntax error |

| 2101 | Unimplemented command |

| 2102 | Unimplemented option |

| 2103 | Unimplemented extension |

| 2104 | Billing failure |

| 2105 | Object is not eligible for renewal |

| 2106 | Object is not eligible for transfer |

| 2200 | Authentication error |

| 2201 | Authorization error |

| 2202 | Invalid authorization information |

| 2300 | Object pending transfer |

| 2301 | Object not pending transfer |

| 2302 | Object exists |

| 2303 | Object does not exist |

| 2304 | Object status prohibits operation |

| 2305 | Object association prohibits operation |

| 2306 | Parameter value policy error |

| 2307 | Unimplemented object service |

| 2308 | Data management policy violation |

| 2400 | Command failed |

| 2500 | Command failed; server closing connecti… |

| 2501 | Authentication error; server closing co… |

| 2502 | Session limit exceeded; server closing… |

There are two types of status codes: server and client. The difference is that all server status codes can only be set and removed by the registry, while the client status codes can also be set and removed by the registrar unless a server status code prohibits it.cite-ref-3-15-1[15]

The server status codes are commonly used to handle domain abuse cases, mark the domain lifecycle stage, or offer extra security against unauthorized tampering, a service often referred to as Registry-Lock.

The client status codes are commonly used also to handle abuse cases, non-payment, invalid contact data, or for a Registrar-Lock feature.

The currently standardized server status codes are:cite-ref-3-15-2[15]cite-ref-1-7-2[7]

| Server Status | Description |

|---|---|

| addPeriod | This grace period is provided after the… |

| autoRenewPeriod | This grace period is provided after a d… |

| inactive | This status code indicates that delegat… |

| ok | This is the standard status for a domai… |

| pendingCreate | This status code indicates that a reque… |

| pendingDelete | This status code may be mixed with rede… |

| pendingRenew | This status code indicates that a reque… |

| pendingRestore | This status code indicates that your re… |

| pendingTransfer | This status code indicates that a reque… |

| pendingUpdate | This status code indicates that a reque… |

| redemptionPeriod | This status code indicates that your re… |

| renewPeriod | This grace period is provided after a d… |

| serverDeleteProhibited | This status code prevents your domain f… |

| serverHold | This status code is set by your domain'… |

| serverRenewProhibited | This status code indicates your domain'… |

| serverTransferProhibited | This status code prevents your domain f… |

| serverUpdateProhibited | This status code locks your domain, pre… |

| transferPeriod | This grace period is provided after suc… |

| Server Status | User required action |

|---|---|

| addPeriod | This is an informative status set for t… |

| autoRenewPeriod | This is an informative status set for a… |

| inactive | If your domain has remained in this sta… |

| ok | Asking your registrar to enact status r… |

| pendingCreate | If the TLD is on a special registration… |

| pendingDelete | If you want to keep your domain name, y… |

| pendingRenew | If you did not request to renew your do… |

| pendingRestore | Watch your domain's status codes within… |

| pendingTransfer | If you did not request to transfer your… |

| pendingUpdate | If you did not request to update your d… |

| redemptionPeriod | If you want to keep your domain, you mu… |

| renewPeriod | This is an informative status set for a… |

| serverDeleteProhibited | This status may indicate an issue with… |

| serverHold | If you provided delegation information… |

| serverRenewProhibited | Often, this status indicates an issue w… |

| serverTransferProhibited | This status may indicate an issue with… |

| serverUpdateProhibited | This status may indicate an issue with… |

| transferPeriod | This is an informative status set for a… |

The currently standardized client status codes are:cite-ref-3-15-3[15]

| Client Status | Description |

|---|---|

| clientDeleteProhibited | This status code tells your domain's re… |

| clientHold | This status code tells your domain's re… |

| clientRenewProhibited | This status code tells your domain's re… |

| clientTransferProhibited | This status code tells your domain's re… |

| clientUpdateProhibited | This status code tells your domain's re… |

| Client Status | User required action |

|---|---|

| clientDeleteProhibited | This status indicates that it is not po… |

| clientHold | Often, this status indicates an issue w… |

| clientRenewProhibited | Often, this status indicates an issue w… |

| clientTransferProhibited | This status indicates that it is not po… |

| clientUpdateProhibited | This domain name status indicates that… |

EPP only offers plain text passwords, additionally the EPP login password type is specified to be a string of 6-16 character lengthcite-ref-0-1-11[1] which might be considered very low for today's standards. Connections over TCP, therefore, must use TLS, and the use of client certificates, as well as correct identity confirmation of the client and server, is strongly encouraged.cite-ref-22[22]

Many domain name registries also offer to set up a IP whitelist for connecting to their EPP servers.

EPP offers some protection against replay attacks via the client generated clTRID, however this element is optional and is therefore not used by every server software. Therefore, additional anti-replay mechanisms should be implemented by the used transport mechanism.cite-ref-0-1-12[1]

• RFC 3375, Generic Registry-Registrar Protocol Requirements

• RFC 5730, Extensible Provisioning Protocol (EPP) (obsoletes RFC 4930, which obsoleted RFC 3730)

• RFC 5734, Extensible Provisioning Protocol (EPP) Transport over TCP (obsoletes RFC 4934)

• RFC 5731, Extensible Provisioning Protocol (EPP) Domain Name Mapping (obsoletes RFC 4931)

• RFC 5732, Extensible Provisioning Protocol (EPP) Host Mapping (obsoletes RFC 4932)

• RFC 5733, Extensible Provisioning Protocol (EPP) Contact Mapping (obsoletes RFC 4933)

• RFC 8543, Extensible Provisioning Protocol (EPP) Organization Mapping

• RFC 3735, Guidelines for Extending EPP

• RFC 3915, Domain Registry Grace Period Mapping (e.g. Add Grace Period, Redemption Grace Period)

• RFC 4114, E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)

• RFC 5076, ENUM Validation Information Mapping for the Extensible Provisioning Protocol

• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) (obsoletes RFC 4310, DNSSEC)

• RFC 8334, Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)

• RFC 8495, Allocation Token Extension for the Extensible Provisioning Protocol (EPP)

• RFC 8544, Organization Extension for the Extensible Provisioning Protocol (EPP)

• RFC 8590, Change Poll Extension for the Extensible Provisioning Protocol (EPP)

• RFC 8748, Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

• RFC 8807, Login Security Extension for the Extensible Provisioning Protocol (EPP)

• RFC 9038, Extensible Provisioning Protocol (EPP) Unhandled Namespaces

• RFC 9154, Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

• RFC 9167, Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)

• WHOIS

• Registration Data Access Protocol

• ICANN

• Internationalized domain name

• Glue record

• RESTful Provisioning Protocol

cite-note-0-11. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721.

cite-note-22. ↑ citerefhollenbeck2001Hollenbeck, S. (2001-05-01). "Extensible Provisioning Protocol". IETF Datatracker. Retrieved 2023-03-13.

cite-note-33. ↑ "IETF December 2000 Proceedings". www.ietf.org. Retrieved 2023-03-13.

cite-note-44. ↑ citerefhollenbeck2004Hollenbeck, S. (March 2004). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3730. ISSN 2070-1721.

cite-note-55. ↑ citerefhollenbeck2007Hollenbeck, S. (May 2007). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC4930. ISSN 2070-1721.

cite-note-11-66. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)".

cite-note-1-77. ↑ citerefhollenbeck2004Hollenbeck, S. (September 2004). "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3915. ISSN 2070-1721.

cite-note-2-88. ↑ "Extensions for the Extensible Provisioning Protocol (EPP)". www.iana.org. Retrieved 2023-03-11.

cite-note-99. ↑ "Implementation Report for RFCs 4930-4934 - Wayback Machine". 2012-01-15. Archived from the original on 2012-01-15. Retrieved 2023-03-12.{{cite web}}: CS1 maint: bot: original URL status unknown (link)

cite-note-1010. ↑ "ICANN base registry contract". newgtlds.icann.org. Retrieved 2023-03-12.

cite-note-1111. ↑ "Official CoCCA website". Retrieved 2023-03-12.

cite-note-1212. ↑ "Introducing FRED - fred". fred.nic.cz. Retrieved 2023-03-12.

cite-note-1313. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Host Mapping". doi:10.17487/RFC5732. ISSN 2070-1721.

cite-note-1414. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Contact Mapping". doi:10.17487/RFC5733. ISSN 2070-1721.

cite-note-3-1515. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN 2070-1721.

cite-note-1616. ↑ citerefzhoukongyaogould2019Zhou, L.; Kong, N.; Yao, J.; Gould, J.; Zhou, G. (March 2019). "Extensible Provisioning Protocol (EPP) Organization Mapping". doi:10.17487/RFC8543. ISSN 2070-1721. S2CID 65065583.

cite-note-1717. ↑ citerefgouldhollenbeck2010Gould, J.; Hollenbeck, S. (May 2010). "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5910. ISSN 2070-1721.

cite-note-1818. ↑ "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)". IETF Datatracker. Retrieved 2023-03-11.

cite-note-1919. ↑ citerefcarneybrownfrakes2020Carney, R.; Brown, G.; Frakes, J. (March 2020). "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC8748. ISSN 2070-1721.

cite-note-2020. ↑ citerefgouldtanbrown2018Gould, J.; Tan, W.; Brown, G. (March 2018). "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC8334. ISSN 2070-1721.

cite-note-2121. ↑ citerefsattlercarneykolker2021Sattler, T.; Carney, R.; Kolker, J. (December 2021). "Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC9167. ISSN 2070-1721.

cite-note-2222. ↑ citerefhollenbeck2009Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Transport over TCP". doi:10.17487/RFC5734. ISSN 2070-1721.